Traffic Flow Confidentiality Enhancements in IPsec: Design and Preliminary Implementation

MOTIVATION Traditional communication security focuses on protecting the delivered contents through strong encryption means. However, extensive literature work demonstrates that encryption alone is insufficient to protect confidentiality. The statistical pattern of the traffic generated in a communication carries plenty of information, which can be maliciously gathered through specially devised attacks. By collecting and correlating statistics such as packet size and inter-arrival times (typically left unaltered by most encryption procedures), a third party may be capable of disclosing information such as the application layer protocols and services employed [1,2,3], the physical devices employed [4], or even specific information related to the delivered contents, most notable being the case of attacks against passwords transmitted over encrypted sessions [5,6]. To duly protect the privacy of the users, further mechanisms are needed in addition to encryption. These are frequently referred to as "Traffic Flow Confidentiality" (TFC) mechanisms. Most of the proposed TFC solutions [7,8,9] are however based on custom frameworks which hardly fit with widely deployed communication security protocols such as IPsec and TLS. Moreover, to provide an effective information hiding, TFC mechanisms should be deployed in conjunction with network-wise anonymization approaches, such as Mix-like protocols [10,11,12], devised to mask further information such as chosen routes, involved endpoints, etc. It would be natural to think to TFC as mechanisms provided by a point-to-point (i.e. per-hop) underlying standard protocol (IPsec being a natural candidate), upon which many different network-wise Mixlike protocols are free to develop their own anonymous routing logic. However, to date, every Mix-like protocol is forced to re-develop from scratch its own TFC suite due to the missing support (e.g. in TLS) or lack of satisfactory TFC support (e.g. in IPsec) in the standard security protocols. CONTRIBUTION IPsec is the only widely deployed security protocol which has partially tackled the issue of supporting TFC mechanisms. The latest specification of the IPsec Encapsulated Security Payload (ESPv3) protocol [13] introduces limited TFC functionalities in terms of i) partial support for packet padding besides the traditional 255 bytes limit, and ii) dummy packet detection and discarding at the receiver side. However, the IPsec TFC support is not fully satisfactory. For instance, no traffic shaping is accounted for, and no padding extension is possible for encapsulated protocols which lack of an explicit “size” field (a notable case being TCP when carried in transport mode over IPsec). Moreover, the latest IPsec specification does not attempt to specify any (albeit simple) Application Programming Interface to manage TFC mechanisms, leaving their control completely up to the implementations. Finally, the IPsec working group has explicitly chosen not to tackle networkwise issues such as support of Mix-like networks. This makes hard to reuse the native IPsec TFC mechanisms, deployed for an IPsec link (namely, a Security Association SA) as primitive services for an overlying network-wise Mix-like protocol, and hence forces Mix-like protocol developers to re-design their own TFC mechanisms. Goal of our work is to propose IPsec enhancements devised to overcome these issues. Specifically, we propose a TFC protocol developed as an extension of IPsec/ESP, specifically as upper sub-layer of ESP. Our TFC protocol is targeted to provide, on one side, an effective support for a variety of TFC mechanisms, and on the other side is devised to simplify the adoption of IPsec (plus our TFC enhancements) as lower layer for Mix-like current and future protocols (and specifically providing per-logical-link TFC mechanisms that overlay network-wise Mix-like frameworks might flexibly exploit and manage). TFC SUB-LAYER DESIGN We propose to develop TFC as an upper sub-layer of the current ESP specification, thus maintaining backward compatibility with traditional IPsec implementations. With reference to Figure 1, which depicts an IPsec/ESP packet, the data contained within the ESP payload (i.e. that included between the ESP header and trailer) are further wrapped in a TFC header which provides a further level of indirection to manage TFC tools. A 4 bytes inner TFC header carries three fields: i) Next Header, ii) Type of Confidentiality Treatment (TOCT), and iii) Padding length.